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ABSTRACT 

Adaptation of software components is an important issue in 
Component Based Software Engineering (CBSE). Building a 
system from reusable or Commereial-Off-The-Shelf (COTS) 
components introduces a set of problems, mainly related to 
compatibility and communication aspects. On one hand, 
components may have incompatible interaction behavior. 
This might require to restrict the system’s behavior to a 
subset of safe behaviors. On the other hand, it might be 
necessary to enhance the current communication protocol. 
This might require to augment the system’s behavior to in¬ 
troduce more sophisticated interactions among components. 
We address these problems by enhancing our architectural 
approach which allows for detection and recovery of incom¬ 
patible interactions by synthesizing a suitable coordinator. 
Taking into account the specification of the system to be as¬ 
sembled and the specification of the protocol enhancements, 
our tool (called SYNTHESIS) automatically derives, in a 
compositional way, the glue code for the set of components. 
The synthesized glue code implements a software coordina¬ 
tor which avoids incompatible interactions and provides a 
protocol-enhanced version of the composed system. By us¬ 
ing an assume-guarantee technique, we are able to check, in 
a compositional way, if the protocol enhancement is consis¬ 
tent with respect to the restrictions applied to assure the 
specified safe behaviors. 

1. INTRODUCTION 

Adaptation of software components is an important issue 
in Component Based Software Engineering (CBSE). Nowa¬ 
days, a growing number of systems are built as composition 
of reusable or Commercial-Off-The-Shelf (COTS) compo¬ 
nents. Building a system from reusable or from COTS M 
components introduces a set of problems, mainly related 

*This work is an extended and revisited version of [7]. 
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to communication and compatibility aspects. Often, com¬ 
ponents may have incompatible interaction behavior. This 
might require to restrict the system’s behavior to a subset 
of safe behaviors. Eor example, restrict to the subset of 
deadlock-free behaviors or, in general, to a specified subset 
of desired behaviors. Moreover, it might be necessary to 
enhance the current communication protocol. This requires 
augmenting the system’s behavior to introduce more sophis¬ 
ticated interactions among components. These enhance¬ 
ments (i.e.: protocol transformations) might be needed to 
achieve dependability, to add extra-functionality and/or to 
properly deal with system’s architecture updates (i.e.: com¬ 
ponents aggregating, inserting, replacing and removing). 

We address these problems enhancing our architectural 
approach which allows for detection and recovery of incom¬ 
patible interactions by synthesizing a suitable coordinator [U 
min]. This coordinator represents a initial glue code. So 
far, as reported in Hisiin], the approach only focussed on 
the restriction of the system’s behavior to a subset of safe 
(i.e.: desired) behaviors. In this paper, we propose an ex¬ 
tension that makes the coordinator synthesis approach also 
able to automatically transform the coordinator’s protocol 
by enhancing the initial glue code. We implemented the 
whole approach in our SYNTHESIS tool O [15] 

( http: // WWW. di. univaq. it/tivoli/S YN THESIS/synthesis.html ) 
In [15], which is a companion paper, we also apply SYN¬ 
THESIS to a real-scale context. Since in this paper we are 
focusing only on the formalization of the approach, in Sec¬ 
tion (5] we will simply refer to an explanatory example and 
we will omit implementation details which are completely 
described in US]. 

Starting from the specification of the system to be as¬ 
sembled and from the specification of the desired behaviors, 
SYNTHESIS automatically derives the initial glue code for 
the set of components. This initial glue code is implemented 
as a coordinator mediating the interaction among compo¬ 
nents by enforcing each desired behavior as reported in [H 
laiii]. Subsequently, taking into account the specification 
of the needed protocol enhancements and performing the 
extension we formalize in this paper, SYNTHESIS auto¬ 
matically derives, in a compositional way, the enhanced glue 
code for the set of components. This last step represents the 
contribution of this paper with respect to m (9] [11] • The en¬ 
hanced glue code implements a software coordinator which 
avoids not only incompatible interactions but also provides 
a protocol-enhanced version of the composed system. More 
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precisely, this enhanced coordinator is the composition of a 
set of new coordinators and components assembled with the 
initial coordinator in order to enhance its protocol. Each 
new component represents a wrapper component. A wrap¬ 
per intercepts the interactions corresponding to the initial 
coordinator’s protocol in order to apply the specified en¬ 
hancements without modifying Q the initial coordinator and 
the components in the system. The new coordinators are 
needed to assemble the wrappers with the initial coordina¬ 
tor and the rest of the components forming the composed 
system. It is worthwhile noticing that, in this way, we are 
readily compose-able; we can treat the enhanced coordina¬ 
tor as a new composite initial coordinator and enforce new 
desired behaviors as well as apply new enhancements. This 
allows us to perform a protocol transformation as composi¬ 
tion of other protocol transformations by improving on the 
reusability of the synthesized glue code. 

When we apply the specified protocol enhancements to 
produce the enhanced coordinator, we might re-introduce 
incompatible interactions avoided by the initial coordinator. 
That is, the enhancements do not hold the desired behav¬ 
iors specihed to produce the initial coordinator. In this pa¬ 
per, we also show how to check if the protocol enhancement 
holds the desired behaviors enforced through the initial co¬ 
ordinator. This is done, in a compositional way, by using an 
assume-guarantee technique [6]. 

The paper is organized as follows: Section discusses re¬ 
lated work. Section [3] introduces background notions helpful 
to understand our approach. Section [H illustrates the tech¬ 
nique concerning the enhanced coordinator synthesis. Sec¬ 
tion [5] formalizes the coordinator synthesis approach for pro¬ 
tocol enhancement in component-based systems, and uses a 
simple explanatory example to illustrate the ideas. Section[6] 
formalizes the technique used to check the consistency of the 
applied enhancements with respect to the enforced desired 
behaviors. Section [7| discusses future work and concludes. 

2. RELATED WORK 

The approach presented in this paper is related to a num¬ 
ber of other approaches that have been considered in the 
literature. The most closely related work is the scheduler 
synthesis for discrete event physical systems using super¬ 
visory control [2]. In those approaches system’s allowable 
executions are specified as a set of traces. The role of the su¬ 
pervisory controller is to interact with the running system in 
order to cause it to conform to the system specihcation. This 
is achieved by restricting behavior so that it is contained 
within the desired behavior. To do this, the system under 
control is constrained to perform events only in strict syn¬ 
chronization with a synthesized supervisor. The synthesis of 
a supervisor that restrict behaviors resembles one aspect of 
our approach defined in Section [U since we also eliminate 
certain incompatible behaviors through synchronized coor¬ 
dination. However, our approach goes well beyond simple 
behavioral restriction, also allowing augmented interactions 
through protocol enhancements. 

Recently a reasoning framework that supports modular 
checking of behavioral properties has been proposed for the 
compositional analysis of component-based design [31 US]- 
In 13], they use an automata-based approach to capture both 

^This is needed to achieve compose-ability in both specifying 
the enhancements and implementing them. 


input assumptions about the order in which the methods of 
a component are called, and output guarantees about the 
order in which the component calls external methods. The 
formalism supports automatic compatibility checks between 
interface models, where two components are considered to 
have compatible interfaces if there exists a legal environment 
that lets them correctly interact. Each legal environment is 
an adaptor for the two components. However, they provide 
only a consistency check among component interfaces, but 
differently from our work do not treat automatic synthe¬ 
sis of adaptors of component interfaces. In m, they use a 
game theoretic approach for checking whether incompatible 
component interfaces can be made compatible by inserting 
a converter between them which satisfies specihed require¬ 
ments. This approach is able to automatically synthesize 
the converter. The idea they develop is the same idea we 
developed in our precedent works m [9l [11]. That is the 
restriction of the system’s behavior to a subset of safe be¬ 
haviors. Unlike the work presented in this paper, they are 
only able to restrict the system’s behavior to a subset of 
desired behaviors and they are not able to augment the sys¬ 
tem’s behavior to introduce more sophisticated interactions 
among components. 

Our research is also related to work in the area of proto¬ 
col adaptor synthesis m- The main idea of this approach is 
to modify the interaction mechanisms that are used to glue 
components together so that compatibility is achieved. This 
is done by integrating the interaction protocol into compo¬ 
nents. However, they are limited to only consider syntactic 
incompatibilities between the interfaces of components and 
they do not allow the kind of protocol transformations that 
our synthesis approach supports. 

In other previous work, of one of the authors, we showed 
how to use formalized protocol transformations to augment 
connector behavior m- The key result was the formal¬ 
ization of a useful set of connector protocol enhancements. 
Each enhancement is obtained by composing wrappers. This 
approach characterizes wrappers as modular protocol trans¬ 
formations. The basic idea is to use wrappers to enhance 
the current connector communication protocol by introduc¬ 
ing more sophisticated interactions among components. In¬ 
formally, a wrapper is new code that is interposed between 
component interfaces and communication mechanisms. The 
goal is to alter the behavior of a component with respect to 
the other components in the system, without actually mod¬ 
ifying the component or the infrastructure itself. While this 
approach deals with the problem of enhancing component 
interactions, unlike this work it does not provide automatic 
support for composing wrappers, or for automatically elim¬ 
inating incompatible interaction behaviors. 

In other previous work, by two of the authors, we showed 
how to apply protocol enhancements by dealing with com¬ 
ponents that might have syntactic incompatibility of inter¬ 
faces [16] . However the approach described in m is limited 
only to consider deadlock-free coordinator. 

3. BACKGROUND 

In this section we discuss the background needed to un¬ 
derstand the approach that we formalize in Sectional 

3.1 The reference architectural style 

The starting point for our work is the use of a formal archi¬ 
tectural model of the system representing the components 
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to be integrated and the connectors over which the compo¬ 
nents will communicate m- To simplify matters we will 
consider the special case of a generic layered architecture in 
which components can request services of components be¬ 
low them, and notify components above them. Specifically, 
we assume each component has a top and bottom interface. 
The top (bottom) interface of a component is a set of top 
(bottom) ports. Connectors between components are syn¬ 
chronous communication channels defining top and bottom 
ports. 

Components communicate by passing two types of mes¬ 
sages: notifications and requests. A notification is sent 
downward, while a request is sent upward. We will also 
distinguish between two kinds of components (i) functional 
components and (ii) coordinators. Functional components 
implement the system’s functionality, and are the primary 
computational constituents of a system (typically imple¬ 
mented as COTS components). Coordinators, on the other 
hand, simply route messages and each input they receive is 
strictly followed by a corresponding output. We make this 
distinction in order to clearly separate components that are 
responsible for the functional behavior of a system and com¬ 
ponents that are introduced to aid the integration/communi¬ 
cation behavior. 

Within this architectural style, we will refer to a system as 
a Coordinator-Free Architecture (CFA) if it is defined with¬ 
out any coordinators. Conversely, a system in which coor¬ 
dinators appear is termed a Coordinator-Based Architecture 
(CBA) and is defined as a set of functional components di¬ 
rectly connected to one or more coordinators, through con¬ 
nectors, in a synchronous way. 



We can also produce a corresponding CBA for these com¬ 
ponents with equivalent behavior by automatically deriving 
and interposing a ’’no-op” coordinator between communi¬ 
cating components. That coordinator does nothing (at this 
point), it simply passes events between communicating com¬ 
ponents (as we will see later the coordinator will play a key 
role in restricting and augmenting the system’s interaction 
behavior). The ”no-op” coordinator is automatically de¬ 
rived by performing the algorithm described in HlHlIII]. 

Formally, using CCS we define the CFA and the CBA for 
a set of components Ci,.., Cn as follows: 

Definition 1. Coordinator Free Architecture (CFA) 

CFA = (Cl I C2 I ... I Cn)\ Ur=i where for all 

i = 1,.., n, Actci is action set of the CCS process Ci. 

Definition 2. Coordinator Based Architecture (CBA) 

CBA ^ (Ci[/?] I C2[m I ... I C4/°] I K)\[j-^,AetcAm 

where for all i — l,..,n, ActCi is the action set of the 
CCS process Ci, and /° are relabelling functions such that 
fi{o) — OL[i/C\ for all a G Actc^] K is the CSS process cor¬ 
responding to the automatically synthesized coordinator. 

By referring to [8], | is the parallel composition operator 
and \ is the restriction operator. There is a finite set of 
visible actions Act — {ai,aj,hh^hk ^...} over which a ranges. 
We denote by a the action complement: if a = %, then 
a = ttj, while if a = cij, then a = aj. By a[i/j] we denote 
a substitution of i for j in a. If a = aj, then a[i/j] = ai. 
Each ActCi — referring to Figure [U 0 identifies the 

only connector (i.e: communication channel) present in the 
CFA version of the composed system. Each relabelling func¬ 
tion fi is needed to ensure that the components Ci, ..Cn no 
longer synchronize directly. In fact by applying these re¬ 
labelling functions (i.e.: /° for all i) each component Ci 
synchronizes only with the coordinator K through the con¬ 
nector i (see right-hand side of Eigure[T]). 


Figure 1: A sample of a CFA and the corresponding 
CBA 

Figure [T] illustrates a CFA (left-hand side) and its corre¬ 
sponding CBA (right-hand side). Ci, C2 and C3 are func¬ 
tional components; iF is a coordinator. The communication 
channels identified by 0, 1, 2 and 3 are connectors. 

3.2 Configuration formalization 

To formalize the behavior of a system we use High level 
Message Sequence Charts (HMSCs) and basic Message Se¬ 
quence Charts (bMSCs) [5] specification of the composed 
system. From it, we can derive the corresponding CCS 
{Calculus of Communicating Systems) processes [8] (and 
hence Labeled Transitions Systems (LTSs)) by applying a 
suitable adaptation of the translation algorithm presented 
in HMSC and bMSC specifications are useful as input 
language, since they are commonly used in software devel¬ 
opment practice. Thus, CCS can be regarded as an inter¬ 
nal specification language. Later we will see an example of 
derivation of LTSs from a bMSCs and HMSCs specification 
fSection l5.ip . 

To define the behavior of a composition of components, we 
simply place in parallel the LTS descriptions of those com¬ 
ponents, hiding the actions to force synchronization. This 
gives a CFA for a set of components. 


3.3 Automatic synthesis of failure-free 
coordinators 

In this section, we simply recall that from the MSCs spec¬ 
ification of the CFA and from a specification of desired be¬ 
haviors, the old version of SYNTHESIS automatically de¬ 
rives the corresponding deadlock-free CBA which satisfies 
each desired behavior. This is done by synthesizing a suit¬ 
able coordinator that we call failure-free coordinator. In¬ 
formally, first we synthesize a ”no-op” coordinator. Second, 
we restrict its behavior by avoiding possible deadlocks and 
enforcing the desired behaviors. Each desired behavior is 
specified as a Linear-time Temporal Logic (LTL) formula 
(and hence as the corresponding Biichi Automaton) [6]. Re¬ 
fer to main] for a formal description of the old approach 
and for a brief overview on the old version of our SYNTHE¬ 
SIS tool. 

4. METHOD DESCRIPTION 

In this section, we informally describe the extension of 
the old coordinator synthesis approach H El E] that we 
formalize in Section [5] and we implemented in the new ver¬ 
sion of the SYNTHESIS tool. The extension starts with 
a deadlock-free CBA which satisfies specified desired be¬ 
haviors and produces the corresponding protocol-enhanced 
CBA. 
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The problem we want to face can be informally phrased as 
follows: let P he a set of desired behaviors, given a deadloek- 
free and P-satisfying CBA system S for a set of hlaek-box 
eomponents interaeting through a eoordinator K, and a set 
of eoordinator protoeol enhaneements E, if it is possible, au- 
tomatieally derive the eorresponding enhaneed, deadloek-free 
and P-satisfying CBA system S'. 

We are assuming a specification of: i) S in terms of a 
description of components and a coordinator as LTSs, ii) P 
in terms of a set of Biichi Automata, and of iii) E in form 
of bMSCs and HMSCs specification. In the following, we 
discuss our method proceeding in two steps as illustrated in 
Figure [21 

In the first step, by starting from the specification of P 
and S, if it is possible, we apply each protocol enhancement 
in E. This is done by inserting a wrapper component W 
between K (see Figure [2|) and the portion of S concerned 
with the specified protocol enhancements (i.e.: the set of 
C2 and C3 components of Figure [2|). It is worthwhile notic¬ 
ing that we do not need to consider the entire model of K 
but we just consider the ”sub-eoordinator” which represents 
the portion of K that communicates with C2 and (73 (i.e.: 
the ”sub-eoordinator” ^ 2,3 of Figure[2|). ^ 2,3 represents the 
”unehangeahle’^ environment that K ”offers” to W. The 
wrapper IF is a component whose interaction behavior is 
specified in each enhancement of E. Depending on the logic 
it implements, we can either built it by scratch or acquire it 
as a pre-existent COTS component (e.g. a data translation 
component). IF intercepts the messages exchanged between 
i^ 2 , 3 , (72 and (73 and applies the enhancements in E on 
the interactions performed on the communication channels 
2 and 3 (i.e.: connectors 2 and 3 of Figure [2|). We first de¬ 
couple K (i.e.: i^ 2 , 3 ), (72 and (73 to ensure that they no 
longer synchronize directly. Then we automatically derive a 
behavioral model of IF (i.e.: a LTS) from the bMSCs and 
HMSCs specification of E. We do this by exploiting our im¬ 
plementation of the translation algorithm described in m- 
Finally, if the insertion of IF in S' allows the resulting com¬ 
posed system (i.e.: S' after the execution of the second step) 
to still satisfy each desired behavior in P, IF is interposed 
between ^ 2 , 3 , C 2 and Cs- To insert IF, we automatically 
synthesize two new coordinators K' and K". In general, K' 


^Since we want to be readily compose-able, our goal is to 
apply the enhancements without modifying the coordinator 
and the components. 


Figure 3: LTSs specification of S and Biichi Au¬ 
tomata specification of P 

always refers to the coordinator between IF and the compo¬ 
nents affected by the enhancement. K" always refers to the 
coordinator between K and IF. By referring to Section [3Tl 
to do this, we automatically derive two behavioral models of 
IF: i) W-TOP which is the behavior of IF only related to 
its top interface and ii) W-BOTTOM which is the behavior 
of IF only related to its bottom interface. 

In the second step, we derive the implementation of the 
synthesized glue code used to insert IF in S'. This glue code 
is the actual code implementing K" and K '. By referring to 
Figure [21 the parallel composition Knew of K, K', K" and 
W represents the enhanced coordinator. 

By iterating the whole approach. Knew may be treated 
as K with respect to the enforcing of new desired behaviors 
and the application of new enhancements. This allows us 
to achieve compose-ability of different coordinator protocol 
enhancements (i.e.: modular protocol’s transformations). In 
other words, our approach is compositional in the automatic 
synthesis of the enhanced glue code. 

5 . METHOD FORMALIZATION 

In this section, by using an explanatory example, we for¬ 
malize the two steps of our method. For the sake of brevity 
we limit ourselves to formalize the core of the extended ap¬ 
proach. Refer to [T] for the formalization of the whole ap¬ 
proach. 

In Figure [3l we consider screen-shots of the SYNTHESIS 
tool related to both the specification of S and of P. Clientl, 
Client2 and Server are the components in S. 
Property-satisfying Coordinator is the coordinator in S which 
satisfies the desired behavior denoted with Alternating Pro¬ 
toeol. In this example. Alternating Protoeol is the only ele¬ 
ment in the specification P. The CBA configuration of S is 
shown in the right-hand side of Figure [1] where (7i, (72, C^ 
and K are Clientl, Client2, Server and Property-satisfying 
Coordinator of Figure [3] respectively. 

Each LTS describes the behavior of a component or of a 
coordinator instance in terms of the messages (seen as I/O 
actions) exchanged with its environment Each node is a 

^The environment of a component/coordinator is the paral- 
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state of the instance. The node with the incoming arrow 
(e.g.: the state S4 of Clientl in Figure EJ is the start¬ 
ing state. An arc from a node ni to a node n 2 denotes 
a transition from m to n 2 . The transition labels prehxed 
by ”!” denote output actions (i.e.: sent requests and notih- 
cations), while the transition labels prehxed by ”?” denote 
input actions (i.e.: received requests and notihcations). In 
each transition label, the symbol followed by a number 
denotes the identiher of the connector on which the action 
has been performed. The hlled nodes on the coordinator’s 
LTS denote states in which one execution of the behavior 
specihed by the Biichi Automaton Alternating Protocol has 
been accomplished. 

Each Biichi Automaton (see Alternating Protocol in Fig¬ 
ure El describes a desired behavior for S. Each node is a 
state of S. The node with the incoming arrow is the initial 
state. The hlled nodes are the states accepting the desired 
behavior. The syntax and semantics of the transition labels 
is the same of the LTSs of components and coordinator ex¬ 
cept two kinds of action: i) a universal action (e.g.: Itrue. 
in Figure [3]) which represents any possible actiorjj, and ii) a 
negative action (e.g.: ! — reqJl in Figure[3]) which represents 
any possible action different from the negative action itsel0. 

Clientl performs a request (i.e.: action !re^_l) and waits 
for a erroneous or successful notihcation: actions ?err_l and 
lokA respectively. Client2 simply performs the request and 
it never handles erroneous notihcations. Server receives a 
request and then it may answer either with a successful or 
an erroneous notihcation 0. 

Alternating Protocol specihes the behavior of S that guar¬ 
antees the evolution of all components. It specihes that 
Clientl and Client2 must perform requests by using an al¬ 
ternating coordination protocol. More precisely, if Clientl 
performs an action req (the transition \reqA from the state 
SAl to the state S50 in Figure [S]) then it cannot perform 
req again (the loop transition ! — req A on the state SbO in 
Figure [3|) if Client2 has not performed req (the transition 
\reqJ2 from the state S50 to the accepting state S125 in 
Figure [3]) and viceversa. 

In Figure [41(a), we consider the specihcation of E as given 
in input to the SYNTHESIS tool. In this example, the 
RETRY enhancement is the only element in E. 

Clientl is an interactive client and once an erroneous no¬ 
tihcation occurs, it shows a dialog window displaying in¬ 
formation about the error. The user might not appreciate 
this error message and he might lose the degree of trust in 
the system. By recalling that the dependability of a sys¬ 
tem rehects the users degree of trust in the system, this ex¬ 
ample shows a commonly practiced dependability-enhancing 
technique. The wrapper WR attempts to hide the error to 
the user by re-sending the request a hnite number of times. 
This is the RETRY enhancement specihed in Figure [31(a). 
The wrapper WR re-sends at most two times. Moreover, 
the RETRY enhancement specihes an update of S obtained 


lei composition of all others components in the system. 
^The prehxed symbols ”!” or ”?”, in the label of a universal 
action, are ignored by SYNTHESIS. 

^The prehxed symbols ”!” or ”?”, in the label of a negative 
action, are still interpreted by SYNTHESIS. 

®The error could be either due to an upper-bound on the 
number of request that Server can accept simultaneously 
or due to a general transient-fault on the communication 
channel. 



Figure 4: bMSCs and hMSC specification of E: 
RETRY enhancement 

by inserting Clients which is a new client. In specifying 
enhancements, we use ” augmented’-hMSCs. By referring 
to [5], each usual bMSC represents a possible execution sce¬ 
nario of the system. Each execution scenario is described 
in terms of a set of interacting components, sequences of 
method call and possible corresponding return values. To 
each vertical lines is associated an instance of a component. 
Each horizontal arrow represents a method call or a return 
value. Each usual HMSC describes possible continuations 
from a scenario to another one. It is a graph with two spe¬ 
cial nodes: the starting and the ending node. Each other 
node is related to a specihed scenario. An arrow represents 
a transition from a scenario to another one. In other words, 
each HMSC composes the possible execution scenarios of the 
system. The only difference between ” augmented”-hMSCs 
and usual bMSCs is that to each vertical line can be associ¬ 
ated a set of component instances (e.g.: {Clientl, Clients} 
in Figure [31 (a)) rather than only one instance. This is help¬ 
ful when we need to group components having the same 
interaction behavior. 

5.1 First step: wrapper insertion procedure 

By referring to Section [31 each enhancement MSCs spec¬ 
ihcation (see Figure [31(a)) is in general described in terms 
of the sub-coordinator Ki (i.e.: KA in Figure [31(a)), the 
wrapper ( WR), the components in S (Clientl) and the new 
components (Clients). The LTS of the sub-coordinator is 
automatically derived from the LTS of the coordinator in S 
(K) by performing the following algorithm: 

Definition 3. construction algorithm 

Let L be the LTS for a component (or a coordinator) C, 
we derive the LTS h > 0, of the behavior of C on 

channels j,..,j+h as follows: 
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1. set equal to L; 


2 . for each loop z^) of labeled with an action 

a = Qk where k ^ j ,j + h do: 

remove (z^, z^) from the set of arcs of 

3. for each arc (z/,/x) of labeled with an action 

a = ak where k ^ j,j + h do: 

• remove (zx,/x) from the set of arcs of 

• if /X is the starting state then 

set zx as the starting state; 

• for each other arc (zx,/x) of do: 

replace (zx,/x) with (zx, zx); 

• for each arc (/x, zx) of do: 

replace (/x, zx) with (zx, zx); 

• for each arc (/x,^;) of with v ^ /j.,iy do: 

replace (/x,x;) with (zx, x;); 

• for each arc ('z;,/x) of with v ^ do: 

replace (x;,/x) with ('z;,zx); 

• for each loop jj) of do: 

replace (/x,/x) with (zx, zx); 

• remove /x from the set of nodes of 

4. until is a non-deterministic LTS (i.e.: it con¬ 

tains arcs labeled with the same action and outgoing 
the same node) do: 

• for each pair of loops (zx, zx) and (zx, zx) of 
labeled with the same action do: 

remove (zx, zx) from the set of arcs of 

• for each pair of arcs (zx,/x) and (zx,/x) of 
labeled with the same action do: 

remove (zx,/x) from the set of arcs of 

• for each pair of arcs ((zx,/x) and (zx, x;)) or ((zx, zx) 

and (zx, x;)) of labeled with the same ac¬ 

tion do: 

— remove (zx, x;) from the set of arcs of 

— if x; is the starting state then 

set zx as the starting state; 

— for each ingoing arc m in x;, outgoing arc out 
from V and loop / on x; do: 

move the extremity on x; of m, out and I 
on zx; 

— remove v from the set of nodes of 

Informally, the algorithm of Dehnition[3] ’’collapses” (steps 
1,2 and 3) linear and/or cyclic paths made only of actions 
on channels k ^ j,j h. Moreover, it also avoids (step 4) 
possible ’’redundant” non-deterministic behavior^. 

By referring to Figure (5] the LTS of Ki is the LTS Re¬ 
stricted Coord. 

In general, once we derived we decouple K from 

the components Cj, Cj-^h (i-e.: Clientl) connected through 
the connectors j,j + /i which are related to the specihed 
enhancement (i.e.: the connector 1). To do this, we use the 
decoupling function dehned as follows: 

^These behaviors might be a side effect due to the collapsing. 



Figure 5: LTSs of wrapper, sub-coordinator and K" 

Definition 4- Decoupling function 
Let Actx be the set of action labels of the coordinator iL, let 
he ID — {j,..., j + /i} a subset of all connectors identifier^ 
of K and let be (5 7 ^ j,.., j + /i a new connector identiher, we 
dehne the ’’decoupling” function as follows: 

• y ai E ActK, if X G /D then: //’"’‘^^^(uz) = as', 

The unique connector identiher S is automatically generated 
by SYNTHESIS. In this way we ensure that K and Clientl 
no longer synchronize directly. In na, we detail the cor¬ 
respondence between the decoupling function and compo¬ 
nents/coordinator deployment. 

Now, by continuing the method described in Section 01 we 
derive the LTSs for the wrapper (see WR in Figure [5} and 
the new components (the LTS of Clients is equal to the 
LTS of Clientl in Figure [3] except for the connector identi¬ 
her). We recall that SYNTHESIS does that by taking into 
account the enhancements specihcation and by performing 
its implementation of the translation algorithm described 
in [T7]. It is worthwhile noticing that SYNTHESIS auto¬ 
matically generates the connector identihers for the actions 
performed by WR and Clients. By referring to Section [3.II 
WR is connected to its environment through two connec¬ 
tors: i) one on its top interface (i.e.: the connector 432 in 
Figure 131(b)) and ii) one on its bottom interface (i.e.: the 
connector 401 in Figure 131(b)). Finally, as we will see in de¬ 
tail in Section [6l if the insertion of WR allows the resulting 
composed system to still satisfy Alternating Protocol, WR is 
interposed between i^i[/ 4 i 7 ], Clientl and Clients. We re¬ 
call that i^i[/ 4 i 7 ] is Ki (see Restricted Coord in Figure [S} 
renamed after the decoupling. To insert WR, SYNTHESIS 
automatically synthesizes two new coordinators K' and K". 
Coordinator in Figure [5l is the LTS for K". For the purposes 
of this paper, in Figure O we omit the LTS for K'. K" is 
derived by taking into account both the LTSs of i^i[/ 4 i 7 ] 
and WR-TOP (see Figure (H) and by performing the old 
synthesis approach n El HU. While K' is derived analo¬ 
gously to the LTSs of Clientl, Clients and WR-BOTTOM 
(see Figure El). The LTSs of WR.TOP and WR.BOTTOM 

®By referring to Section El the connectors identihers are 
posthxed to the labels in Aetx- 
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are WRa ^2 and WRaqi respectively. By referring to Defi¬ 
nition [3l WRa 2,2 and WRaqi model the behavior of WR on 
channels 432 and 401 respectively. The resulting enhanced, 
deadlock-free and Alternating Pro toco/-satisfying system is 
S' = {{Clienti \ Client 2 \ Clients \ Server \ Knew) \ 
(^Actciientl^ Act(Jlient 2 ^ ActServer^ ActciientC)) whcrC Knew 
= {{K[fhr] \WR\K'\ K") \ {ActwRVJ (see 

Figure [31(b)). In [T], we proved the correctness and com¬ 
pleteness of the approach. 

5.2 Second step: synthesis of the glue code 
implementation 

The parallel composition Knew represents the model of 
the enhanced coordinator. By referring to Section (31 we re¬ 
call that K is the initial glue code for S and WR is a COTS 
component whose interaction behavior is specified by the 
enhancements specihcation E. That is, the actual code for 
WR and K is already available. Thus, in order to derive 
the code implementing Knew, SYNTHESIS automatically 
derives the actual code implementing K' and K". Using 
the same technique described in SI El ttn US], this is done 
by exploiting the information stored in the nodes and arcs 
of the LTSs for K' and K". More precisely, the code im¬ 
plementing K' and K" reflects the structure of their LTSs 
which describe state machines. For the sake of brevity, here, 
we omit a detailed description of the code synthesis. Refer 
to [31[9l [TTl [15] for it. In [9l [15], we validated and applied 
SYNTHESIS for assembling Mierosoft COM/DCOM com¬ 
ponents. The reference development platform of the current 
version of SYNTHESIS is Mierosoft Visual Studio 7.0 with 
Aetive Template Library. 

6 . CHECKING ENHANCEMENT 
CONSISTENCY 

In this section we formalize a compositional technique to 
check if the applied enhancements are consistent with re¬ 
spect to the previously enforced desired behaviors. In other 
words, given the Biichi Automata specification of a desired 
behavior P^, given the deadlock-free and P^-satisfying coor¬ 
dinator K and given the MSCs specification of an enhance¬ 
ment Pi, we check (in a compositional way) if the enhanced 
coordinator Knew still satisfies Pi (Knew Pi). 

In general, we have to check \ WR \ K' \ 

K") \ {ActwRV Act rfj,..,j+hA) ^ Pi. By exploit- 

ing the constraints of our architectural style, it is enough 
to check I K's') \ ^ Pi 

where {j,.., j + ?n} is the set of channel identifiers which are 
both channels in {j,.., j + /i} and in the set of channel iden¬ 
tifiers for the action labels in Pi. In order to avoid the state 
explosion phenomenon we should decompose the verifica¬ 
tion without composing in parallel the processes 
and K'f. We do that by exploiting the assume-guarantee 
paradigm for compositional reasoning [ 6 ]. 

By recasting the typical proof strategy of the assume- 
guarantee paradigm in our context, we know that if 
{A)K[fi'"'^^'^]{Pi) and {true)K'f {A) hold then we can con¬ 
clude that 

{true) I Kg) \ Actj^ 

true. This proof strategy can also be expressed as the fol¬ 
lowing inference rule: 


{true) K'^ {A) 

_ {A)K[fP'^+^]{Pi) _ 

{true){{K[fl’--’^^'^\\K'l)\Act 

where A is a LTL formula (and hence it is modeled as a 
Biichi Automaton). We recall that, in S', K already satisfies 
Pi. Once we applied Ei to obtain the enhanced system S' , A 
represents the assumptions (in S') on the environment of K 
that must be held on the channel S in order to make K able 
to still satisfy Pi. Without loss of generality, let {j ,.., j + m} 
be Channelsp^ fl {j ,.., j + /i} where Channelsp^ is the set of 
channel identifiers for the action labels in P^; then A is the 
Biichi Automaton corresponding to Pj,.., j+r.[fr’^+n[fenv] 
where fenvijo:) = and fenv^o:) = ?a. For the example 
illustrated in Section [5] K'f and A are the Biichi Automata 
corresponding to P 417 (i.e.: K2 showed in Figure [ 6 ]) and 
to Ki[fliY][fenv] {AssumpUon showed in Figure [ 6 ]) respec¬ 
tively. 




fsS 


Figure 6: Biichi Automata of P417, Pi [/417] [/en^;] and 

-^1 [/ 417 ] [fenv] 

In general, a formula {true)M{P) means M |= P. While 
a formula {A)M{P) means if A holds then M ^ P. In 
our context, P is modeled as the corresponding Biichi Au¬ 
tomaton Bp. M is modeled as the corresponding LTS. By 
referring to [ 6 ] , to a LTS M always corresponds a Biichi Au¬ 
tomaton Pm. With L{B) we denote the language accepted 
by B. Exploiting the usual automata-based model checking 
approach [ 6 ] , to check if M ^ P we first automatically build 
the product language Lmhp = L(Bm) H L(Pp) and then 
we check if Lmhp is empty. 

Theorem 1. Enhaneement eonsisteney eheek 
Let Pi be the Biichi Automata specification of a desired 
behavior for a system S formed by Ci,..,Cn components; 
let P be the deadlock-free and P^-satisfying coordinator for 
the components in S; let Ei be the MSCs specification of 
a P-protocol enhancement; let K" be the adaptor between 
P and the wrapper implementing the enhancement Ep, let 
S the identifier of the channel connecting K" with P; let 
{l ■■C + fhe set of channel identifiers which are both 
channels in the set of channel identifiers for the action labels 
in Pi and in the set of channels identifiers affected by the 
enhancement Ei; and let fenv be a relabeling function in 
such a way that /env(?Q^) = and fenv^Oi) = ?<a for all 
a e ActK, if 1 = 0 then 

I Kg) \ Actj^^ ^ a hence 

Ei is consistent with respect to Pi. 
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Proof. Let A be the Biichi Automaton corresponding to 

if .. ,j + rnj = 0 

then |= A. That is, {true)K'^{A) holds. Moreover, by 
construction of A, (A}K[f^'"'^~^'^](Pi) holds too. By ap¬ 
plying the inference rule of the assume-guarantee paradigm^ 
{true){{K[fl’-’^+'^] I Ks)\Act^_^ is true 

and hence \ Kg) \ ^ 

Pi. □ 

By referring to Theorem [U to check if Ei is consistent with 
respect to Pi, it is enough to check if {true)K'^{A) holds. 
In other words, it is enough to check if K" provides K with 
the environment it expects (to still satisfy Pi) on the chan¬ 
nel connecting K" to K (i.e.: the connector identihed by 

(5). In the example illustrated in Section [5l RETRY is con¬ 
sistent with respect to Alternating Protocol In fact, by re¬ 
ferring to Figure [6l NOT{A) is the Biichi Automaton for 
^^[fli 7 \[fenv\ (i.e.: for A of Theorem [T]) and K 2 is the 
Biichi Automaton for K 41 Y (i.e.: for of Theorem [1]). By 
automatically building the product language between the 
languages accepted by iF2 and NOT (A), SYNTHESIS con¬ 
cludes that ~ ® hence that 

{{K[fliY] I \ ^ Alternating Protocol That 

is RETRY is consistent with respect to Alternating Protocol 

7. CONCLUSION AND FUTURE WORK 

In this paper, we combined the approaches of protocol 
transformation formalization m and of automatic coordi¬ 
nator synthesis H El HI] to produce a new technique for 
automatically synthesizing failure-free coordinators for pro¬ 
tocol enhanced in component-based systems. The two ap¬ 
proaches take advantage of each other: while the approach of 
protocol transformations formalization adds compose-ability 
to the automatic coordinator synthesis approach, the latter 
adds automation to the former. This paper is a revisited 
and extended version of [7]. With respect to [7], the novel 
aspects of this work are that we have dehnitively hxed and 
extended the formalization of the approach, we have imple¬ 
mented it in our ’’SYNTHESIS” tool and we have formalized 
and implemented the enhancement consistency check. 

The key results are: (i) the extended approach is compo¬ 
sitional in the automatic synthesis of the enhanced coordi¬ 
nator; that is, each wrapper represents a modular protocol 
transformation so that we can apply coordinator protocol 
enhancements in an incremental way by re-using the code 
synthesized for already applied enhancements; (ii) we are 
able to add extra functionality to a coordinator beyond sim¬ 
ply restricting its behavior;(iii) this, in turn, allows us to en¬ 
hance a coordinator with respect to a useful set of protocol 
transformations such as the set of transformations referred 
in m- The automation and applicability of both the old 
(presented in [ll[9l[TT]) and the extended (presented in this 
paper and in m approach for synthesizing coordinators is 
supported by our tool called ’’SYNTHESIS” ITS]. 

As future work, we plan to: (i) develop more user-friendly 
specihcation of both the desired behaviors and the protocol 
enhancements (e.g., UML2 Interaction Overview Diagrams 
and Sequence Diagrams); (ii) validate the applicability of 
the whole approach to large-scale examples different than 
the case-study treated in US] which represents the hrst at¬ 
tempt to apply the extended version of ’’SYNTHESIS” (for¬ 
malized in this paper) in real-scale contexts. 
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